Je suis d'accord dans le principe de possibilité.
Mais pas d'accord sur le fond.

EDF (enfin ERDF) ne se sert de Linky que pour la télé-relève, bref le comptage. Les données ont une durée de vie, un "purpose", des suppressions automatiques en cas d'alerte sécurité, etc, bref, tout ce qui fait rêver quelqu'un travaillant dans le domaine de la vie privée : pour une fois, ça semble propre.
Ce qui rassure le plus dans tout ça, c'est que le business model d'EDF / ERDF n'est pas basée là dessus. Leur économie, ils l'ont déjà faite (enfin ils l'amortiront sur des années) en économisant sur la relève manuelle du comptage. Et vu qu'ERDF est à l'origine de G3 (la techno CPL derrière Linky), ils peuvent aussi revendre l'expertise en Europe et dans le monde.
Les compteurs communicants sont une recommandation (en gros une obligation) de l'union européenne (d'ici 2020 il me semble). C'est plutôt encourageant qu'ERDF ait pris la chose à bras le corps, plutôt que de claquer une solution moisie.
Voir l'avis de la CNIL sur le sujet : https://www.cnil.fr/fr/compteurs-communicants-linky-la-position-de-la-cnil-sur-le-stockage-local-de-la-courbe-de-charge-0

Je m'inquièterai davantage sur la sécurité de la communication. Le CPL rassure déjà pas mal par rapport à du sans-fil (même si en émettant comme un bourrin, on peut réussir à le capter un peu en étant très proche).
Je connais une des personnes ayant travaillé à la spécification du G3, notamment la partie sécurité (je parle ici de l'aspect protocolaire). Il est plutôt du genre "pénible" quand il s'agit de sécurité, même pour des prototypes où on aimerait sans passer. Accessoirement, il connait son sujet ;-) Vu qu'il n'est pas sans cesse en train de se plaindre de la sécurité du G3, comme il le fait pour le G1 par exemple, ça me rassure un tantinet.

D'autre part, dans les compteurs il y a de la place pour un module externe permettant de communiquer les infos à des tiers en local (i.e. sans passer par ERDF, mais les tiers peuvent aussi nous demander si on est d'accord qu'ERDF leur file ces infos. A condition qu'on est au préalable autoriser ERDF à les avoir). Mais ce n'est pas forcément un tiers, ça peut être soi-même : on peut imaginer un boitier Wi-Fi / ZigBee / BLE par exemple pour interfacer son compteur à son RaspberryPi ou autre.
Les infos reçues sont celles de la TIC (https://www.planete-domotique.com/blog/2010/03/30/la-teleinformation-edf/), peu ou prou les mêmes informations que nos compteurs actuels. Donc si ça vous inquiète, soyez inquiet dès maintenant.

Il y a tellement de monde sur qui taper, ceux qui se plantent (volontairement ou non) sur les aspects vie privée, sécurité, usage, ... Pour une fois que c'est fait proprement, je pense qu'on peut s'en satisfaire.
Personnellement, je rapproche cela des portiques Navigo en Ile-de-France : ils ont conçu leur architecture pour que le système ne puisse suivre à la trace un utilisateur. Bref, c'est propre. ça avait fait du bruit à l'époque.

Pour gérer proprement les erreurs dans les réponses d'un API REST, le mieux est de n'utiliser que les "Status Code" HTTP (404, 400, ...). Parfois cela ne suffit pas.
Dans ce cas, le mieux est d'utiliser :

• la nouvelle RFC 7807 qui permet d'ajouter des informations à un "Status Code" HTTP : http://www.bortzmeyer.org/7807.html
• le mécanisme similaire de JSONAPI : http://jsonapi.org/format/#errors

Vu qu'on utilise déjà ce type de mécanisme aujourd'hui, je pense qu'au moins l'un des deux sera très vite adopté et qu'on s'y retrouvera beaucoup plus rapidement en découvrant une nouvelle API !

I often refer to this quote, sometimes attributed to Albert Einstein and sometimes to Yogi Berra: In theory, theory and practice are the same. In practice, they are not.

Oui, un framework Web en Qt.

For our purposes, we will define "C++ Type Constraint" in the following way:

A C++ Template will have one or more type arguments. The template may require that each argument fullfill more or more conditions in order for the template to compile without error. These requirements are called Type Constraints or Type Requirements.

C++ literature and documentation use the word Concept for this purpose. In fact, this usage of the word Concept is one of the reasons that the subject has been so confusing. Another reason is that it is really only necessary to understand Concepts when writing a templated library. Since very few programmers actually write such code, very few people actually use this idea and hence are unfamilar with it. Our term Type Constraint is exactly equivalent to the C++ term Concept. Either one can be substituted for the other without loss of meaning.

Un des trucs qui me fascine en C++, c'est que sa communauté contient beaucoup de personnes qui semblent fichtrement intelligentes et qui se posent des problèmes et des questions invraisemblable.
On retrouve ça ailleurs, comme une partie de la communauté Javascript par exemple (dingue), mais pas partout.

Comment coder HTML/CSS pour des emails ! J'avais zappé cet article à Noël.

Réussir une jolie API REST avec de belles réponses en JSON, penser à faire de l'HTTPS, et oublier l'authentification, c'est quand même dommage...
En prime l'API en elle-même fournit déjà tellement d'information : le VIN est un identifiant unique du véhicule c'est une hérésie de l'utiliser en direct, et il aurait fallu passer les paramètres dans le body HTTP pour qu'ils soient chiffrés par HTTPS (quit à être moins RESTfull).

Les constructeurs automobiles vont vraiment devoir se muscler à ce niveau là, c'est une telle machinerie quand les pièces doivent être prêtes à partir en usine qu'il faut vraiment être costaud pour avoir le temps de penser à tout dans le temps imparti et avec toutes les contraintes métiers.

sudo apt-get install dnsmasq